Modern firms use complex business systems to define and perform the business processes used by the firms. The business system typically includes a variety of backend applications to perform related tasks and define related processes, such as inventory management, employee management, customer relations, etc. Each application makes use of a variety of business objects, which contain data and business logic to manipulate the data.
Typically, the user interface used to access these backend applications does not include any business or functional logic itself. Rather, the backend applications provide functions and services to the user interface, which provides communication between a user and the applications using the services provided by the applications. Thus, the functionality presented by the user interface is limited by the services exposed by the backend applications.
An application user interface (UI) is typically coupled to the backend applications using a request-response model. That is, the UI sends a request to the backend and waits for a resulting response. Communication between the UI and the backend applications can use a stateless connection or a stateful connection. In a stateless connection, each request is independent of each other request. That is, a later request does not use or rely on information from an earlier request. In a stateful connection, operations may be linked or related to earlier requests. For example, a later request may rely on the result of an operation resulting from an earlier request. Stateless connections generally allocate memory and network resources for each request/response cycle separately, but can result in higher response times if more data must be transported with each request or if the application has high initialization costs. Stateful connections typically have faster response times, but may impose higher memory and network connections on the back end since connections are kept open while the application is running.
It is normally necessary to specify whether an application and the corresponding UI will use a stateful connection or a stateless connection during development of the application, i.e., before it is customized and installed for a specific customer. This decision results in different design structures at various layers of the application, such as when a model/view/controller approach is used, and therefore cannot later be adjusted for a specific business system.
However, each customer may want to adjust various applications to perform in different modes than are selected when the applications are developed. For example, it may be desirable to specify some applications in a business system as stateful, and others as stateless, depending on the resources available to the system and the expected frequency and character of the use for each application. Since these factors may vary by customer and business system, it is difficult to select a communication mode that will be useful across a wide range of business systems.
One approach is to create two versions of each application and associated services, with one version designed as a stateless application, and the other as a stateful application. However, this can cause unnecessary complexity when developing the business system, since a change made to the application will have to be made in each version separately. It can also result in a system that makes inefficient use of resources. Since most businesses will only require one version of each application (stateful or stateless, depending on the specific environment), the business system may require a good deal more storage and/or processing resources than would be required if each application had a single version.
Thus there is a need in the art for systems and methods to allow for flexibility in connection mode selection for applications in a business system, where the connection and processing mode of each application can be selected during configuration or customization of the business system.